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Abstract: It is argued that the next wave of software process improvement 
(SPI) activities will be based on a People-centered paradigm. The most 
promising such paradigm, Watts Humphrey’s Personal Software Process 
(PSP) is summarized and its advantages are listed. The concepts of the PSP 
are shown to also fit a down-scaled version of Basili’s experience factory. The 
author’s data and lessons learned while practicing the PSP are presented 
along with personal experience, observations and advice from the perspective 
of a consultant and teacher for the Personal Software Process. 
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1 Toward a People-centered SPI paradigm 


The Capability Maturity Model (CMM) and CMM-based SPI paradigms have had a profound 
impact on the organizational practices within the software industry [Herbsleb-94], Other SPI 
paradigms such as the experience factory have been demonstrating the value of experiment 
based software improvement for over 1 5 years [IEEE-94], In spite of these progress, we tech- 
nologists, process advocates and other change agents still have to fight an entrenched and 
pernicious resistance. 

To better ascertain what to do about this, we must understand where we have been and where 
we want to go next. As Basili puts it in [Basili-89]: 

We have evolved from focusing on the project, e.g. schedule and re- 
source allocation concerns, to focusing on the product, e.g. reliability 
and maintenance concerns, to focusing on the process, e.g. improved 
methods and process models’ 

However, addressing the practitioner’s resistance from healthy skepticism to outright obscu- 
rantism is not a technical problem; it is a human concern. Perhaps accelerated progress re- 
quires that we now continue the evolution by focusing on the People, e.g. individual education 
and practices based on individual self improvement. 

Major relatively new concepts such as the CMM or the experience factory are both intellectu- 
ally satisfying and daunting to practice at the individual level. As a programmer, I may well un- 
derstand the importance of the practices of the subcontract management KPA while at the 
same time failing to relate to any of them in my individual work. As a reuse technologist, I may 
be totally convinced that my company should operate as an experience factory while at the 
same time having no idea how to incorporate the concepts in my day to day practice. 

Conversely, I may be highly skeptical of ‘their’ SCEs, ‘their’ pilot project, and God knows what 
other latest fad. I will remain unconvinced until ‘they’ show me that it will really work for me. I 
may have heard good things about clean room, I may even have watched a convincing pre- 
sentation at the Software Engineering Workshop about it. If I have never personally experi- 
enced it, it will remain alien to me, something even vaguely frightening that I will keep resisting. 
In the word of a most famous (and anonymous) Chinese proverb: 

7 hear and I forget, I see and I remember, I do and I understand’ 

A more personal and more practical approach to software improvement where the individual 
practitioner learn by doing, may be needed to accelerate the transition of better engineering 
practices throughout our organizations. 
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2 The Personal Software Process 


As students, we typically practice on toy problems in programming language classes. Our ad 
hoc processes are sufficient to produce moderate size programs quickly and get a passing 
grade. As programmers we quickly discover that these student practices do not scale up but 
what can we do?. The product must be out the door if we want to work on the next one. There 
is very little time to experiment with something unproven. 

The personal software process was developed by Watts Humphrey to indoctrinate students 
(in university and industry alike) in the use of large scale methods based on the CMM. To 
quote Watts in [Humphrey-95], the PSP... 

'... scales down industrial software practices to fit the needs of small scale 
program development. It then walks you through a progressive sequence of 
software processes that provide a sound foundation for large-scale software 

development’ 

Using fairly simple and well proven engineering principles, the PSP student plans his work, 
enacts a well defined process, building the product while gathering data, and performs a post 
mortem that seeds the next improvement cycle. This personal approach to software improve- 
ment offers the following advantages: 

• By having to adhere to more disciplined practices, students learn a lot about 
process, engineering, and software improvement. Most become motivated to 
learn even more about their field 

• By gathering their own private data, students quickly build a significant 
experience base which allow them to set new goals, perform the next 
experiment and check the results against the goals 

• Since the data is personal and private, PSP practitioners need no convincing 
from anyone about the value of a process step or a technology. They know 
whether it works for them or not based on their own quantitative results 

• Armed with their own productivity and quality statistics, practitioners of the 
PSP are better able to make commitments they can meet. They can also 
better resist unreasonable commitment pressures 

The PSP course leads the student to the gradual application of software engineering discipline 
through a set of 10 assignments: 

1. Average and standard deviation using linked list 

2. Physical line counter 

3. Object LOC counter (build on 2) 

4. Linear regression using linked list (build on 1) 

5. Standard distribution (integration by the method of Simpson) 

6. Linear correlation (build on 5) 
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7. Confidence intervals (build on 5 & 6) 

8. Sorting a set of numbers in ascending order 

9. Performing statistical fit tests on the above data 

10. Computing muti-linear regression coefficients (by solving a system of linear 
equations) 

These simple exercises were found to have the following advantages: 

• Simplicity without being trivial. 

• Fostering reuse and good object oriented development practices 

• Gradually building a small PSP support toolset 

The PSP data shown on the transparencies was collected during Watts Humphrey’s Spring 94 
course for the Master of Software Engineering at CMU. 
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3 Personal data, experience, and lessons learned 

Several PSP reports have to be written as part of the course detailing: 

• Evolution of size and time estimates accuracy 

• Pareto charts and checklist for defects 

• Defect injection and removal trends 

• Cost per defect type and injection/removal phases 

• Process development process for PSP reports 

• Detailed process analysis such as A/F ratio 

• Lessons learned 

• Future steps 

The large number of graphs could not be reproduced here or even shown during the talk. 
Watts Humphrey’s data analysis diskette (which can be obtained with the book [Humphrey- 
95]) includes an optimum set of Excel templates and macros for PSP data analysis. I found it 
very useful to track my progress and accelerate the routine of the post mortem analysis. 

A central part of my talk dealt with the application of the concepts of experience factory to my 
PSP results. The experience gathered can be summarized as follow: 

• The accuracy of my time and size estimates improved from +-40% to +-20% 
over the 10 assignments of the PSP. 

• The PSP linear regression model helped me increase the accuracy of my 
size estimates. The multi linear coefficients computed by program 10 offer 
great potential to similarly increase the accuracy of my time estimates. 

• The percentage of development time spent compiling decreased from 15% 
to 5%. 

• My productivity during the development phase remained at 20 LOC/hr. 

• I made a humiliating number of syntax errors with a language I know well until 
I truly inspected my code BEFORE compiling it. 

• My error injection rate decreased from 1 80/kLOC to 30/kLOC and from 4 
defect/hr to less than 1 defect/hr. 

• From assignment 4 on, the sum of my code reuse and code developed for 
reuse stayed at about 80%. 

• Defect fix cost varied from 1 min/defect to 8 min/defect depending on phase 
injected/removed. 

• The process development process I enacted to develop a report 
development process for my PSP experience reports was an overkill. But I 
learned a lot trying that hard. 

Building on this experience, I have applied the GQM paradigm to the definition of my next pro- 
cess improvement steps: 
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• Reduce my error injection rate to less than 20 defects/kLOC 

• Improve my error detection processes 

• Keep design and code inspection yields above 50% 

• Keep formal pre-compile inspection yield above 80% 

• Strive for zero compile error 

• Improve my testing process to a yield over 50% 

• Keep containing costs 

• Keep personal and informal review rates above 200 LOC/hr 

• Keep formal inspection rates above 100 LOC/hr 

• Increase reuse 

• Either assemble 80% of the software out of reusable components 

• Or make reusable components out of at least 50% of the new code 

• Formalize the experience gathered with the PSP by applying experience 
factory concepts 
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4 Teaching the PSP 

SEI has already conducted one T rain the trainer' course In Pittsburgh from October to Decem- 
ber 1 994. 1 taught the 2 lectures on design in that occasion. Besides the usual lessons learned 
from our own lectures, I think all instructors agreed that: 

• The PSP is not your usual “teach and run” course 

• Serious commitment is necessary from both student and sponsor 

• A qualified instructor is necessary to get long term results 

The PSP is about behavioral change. It is not a typical lecture course. It is a 200 hr intensive 
educational experience. The lectures are but the tip of the iceberg. The instructor must spend 
a significant amount of time tutoring the student in the correct implementation of the organiza- 
tion’s process. The students don’t just sit there either, they write working programs. These pro- 
grams have to be reviewed and corrected. The process must be analyzed and feedback must 
be given. The PSP is more like a complete training program (in the sense of the CMM level 2 
KPA) and typically spans 20 weeks. Strong commitments are necessary: 

• from the student to honestly work the exercises, improve his process, and to 
finish the course 

• from the sponsor to allow the time necessary for the lectures and for part of 
the implementation of the programs (typically shared 50/50 between sponsor 
and student) 

Best resuts are seen when the sponsor treats the PSP assignment as any other (assuming 
correct project tracking and oversight practices). This means that the student’s assignments 
are integral part of the workday and are part of his deliverables. 

The PSP also requires a dedicated and qualified instructor with demonstrated programming 
and software management experience. Based on historical data, the effort necessary to cor- 
rectly teach the PSP is roughly: 

• Lecture preparation: 2-4hrs/lecture 

• Tutoring: 5-10 hrs/student 

• Program & process analysis: 2-10 hrs/student 

Anything less has a great chance of failing to make a lasting difference in the disciplined, qual- 
ity-driven individual practices demonstrated in the PSP course. 
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5 Conclusions 


The PSP gives me the opportunity to improve the quality of the software I produce by offering 
a framework for objective measurement and improvement of my practices. However, the ac- 
curacy and the consistency of the data gathering process is paramount. Watts made this point 
very clear throughout the course. Nevertheless, it took me quite a while to truly understand 
why. I believe that a strict data inspection process should be enacted and particularly strongly 
enforced at the beginning of a PSP course to ensure that all students start on the right foot. I 
also believe that the postmortem phase should be expanded to include the systematic analysis 
and archiving of lessons learned with the assignment at hand. I have modified my own PSP 
accordingly. 

I believe that the PSP is not only about scaling down the CMM. It can also be seen as a scaled 
down experience factory. It is because the PSP encompasses such an elegant synthesis of 
large scale methods that it will power the next wave of software practice improvement. 

By practicing the PSP, I have learned a great deal about enacting, improving and even devel- 
oping personal processes. I have carried the very simple principles of the PSP and the process 
development methodology described in chapter 13 of [Humphrey-95] to other processes: 

• The organization of my work day 

• A consulting personal process 

• A process to perform Rate Monotonic Analysis 

• A family of processes to write papers and reports. 

These have been very exciting first steps. 
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The Personal Software Process 

Programming language class practices do not scale up 

Corporate wide efforts encounter increasing resistance 
on the way down. 

The PSP: 

“Scales down industrial software practices to 
fit the needs of small scale program 
development. It then walks you through a 
progressive sequence of software processes 
that provide a sound foundation for large-scale 
software development. n1 


2 1 Wans Humphrey. “A discipline of software engineering". Addison WtsJcy, December 1994. 



KPAs scaled down for the PSP 
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The Experience Factory context 1 
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The Experience Factory structure ^ 


Project Organization Experience Factory 
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The PSP assignments as experiments 

Goal: 

• Actual staff-hours will be within 20% of estimates 
80% of the time. 

Questions: 

• How do I predict my effort now? 

• How do I measure the actual effort? 

• How do I track actual against estimates? 

• What is the dispersion now? 

• If I had a data base of these, I could get statistics 

Metrics: 

• Estimate in mn before, measure actuals during 

• Compute linear regression and confidence intervals 
from the data base. Accuracy is given by stats. 
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Productivity Range 
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Size prediction model (dmr data) 


Size prediction model 
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Cost of error (dmr data) 


Time to tx defect 
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Defects analysis (dmr data) 


Syntax errors 





Defect type 
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Reuse trends (dmr data) 
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Ada PSP: Some experience artifacts 


“/ hear and I forget. I see and I remember, I do 
and I understand ” 


A lot of very useful process data: 

• predicted and actual time per phase 

• error classes and distribution 

• linear regression models for size and cost estimates 

• trend analysis graphs on all of the above 

• post mortems and reports as experience base 

• a deeper understanding of PSI that carries beyond 
software development 

A lot of new goals and ideas to try next 
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Some of my next goals: 

Reduce my total defect injection rate to less than 20 per 
KLOC. 

Optimize my set of inspection processes to reduce their 
cost to less than 1 inspection staff-mn per SLOC while 
keeping yield above 80% 

Either build with reuse (at least 80% of total SLOC) or 
build for reuse (at least 50% of the new code is reusable) 

Revisit the PSP in the light of the CMM and ISO 9000-3 

Recast the PSP in the experience factory mold 
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PSP: The experience workshop 


Plan/Do 


Check/Act 



SEW Proceedings 


109 


SEL-94-006 









Camog* Melon University 

Software Engineering Institute 


Conclusion 

The PSP represents an elegant synthesis of proven concepts 
(CMM, experience factory) scaled down to the individual level. 

Preliminary PSP results are encouraging. Team data is needed. 

Until now: 

“We have evolved from focusing on the project, e.g. 
schedule and resource allocation concerns, to 
focusing on the product, e.g. reliability and 
maintenance concerns, to focusing on the process, 
e.g. improving methods and process models”' 

Future progress may well hinge on focusing on the People. 


15 |. From "Software Development: A Paradigm for the Future". Vjcux R. Basil!. Proc. 1 3th Ini' I Computer Software &. Applications Conf. OrlarxJc FL. Sop 89 
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PSP Status 

The PSP was developed by Watts Humphrey 

Several industrial organizations are now introducing 
PSP methods (DEC, HP, Tl) with encouraging results 

SEI is offering train the trainer courses 

Several universities are teaching the PSP (CMU, U. of 
Mass., Howard U., Embry-Riddle U., McGill, and others) 

The textbook “A Discipline for Software Engineering” 
and support diskette are available from Addison 
Wesley. 
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Questions 


For more information or off-line discussion contact: 

Daniel Roy 
20 Forest Rd 

Bradford Woods PA 15015 
(412) 934 0943 
dmr@sei.cmu.edu 
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Session 3: Certification 


Applying Program Comprehension Techniques to Improve 
Software Inspections 
Stan Rifkin, Master Systems Inc. 


An Experiment to Assess the Cost-Benefits of Code Inspections in Large-Scale 

Software Development 
Harvey Siy, University of Maryland 


A Process Improvement Model for Software Verification and Validation 
Jack Callahan, NASA Independent Software Verification and Validation Facility 
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